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I. Real Party in Interest 

The patent application that is the subject of this appeal is assigned to Illinois Tool Works, 

Inc. 

II. Related Appeals and Interferences 

There are no appeals or interferences that are related to this appeal. 

III. Status of Claims 

The application, as fded, included 26 claims. Of these, claims 1-6, 13-17, and 23-26 
have been withdrawn. 

Claims 7-12 and 18-22 have been rejected. No claims have been allowed. 
Applicants appeal the rejection of claims 7-12 and 18-22. 

IV. Status of Amendments 

No amendments have been entered subsequent to the Final Rejection mailed on June 2, 
2006. Accordingly, the Claim Appendix reflects the claims as of that date. 

V. Summary of the Claimed Subject Matter 

In the discussion which follows, the actual language of the claims is set forth in bold text. 
Reference symbols, citations to the specification, and explanations are set forth in non-bold text. 

7. An automated method for reporting in a supply chain (10 in 

Figures 1 and 6) involving an enterprise (16 in Figure 1, "OEM" in Figure 4) 
and at least one partner (18 in Figures 1 and 6, "3PL" in Figure 4), the method 
comprising: 

Figure 1 illustrates a supply chain system 10 in which an enterprise domain 16 is linked 
by a network domain 14 to multiple partner domains 18 and customer domains 20. Figure 4 
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presents a specific example of a transaction where an original equipment manufacturing 
enterprise "OEM" is linked by a network domain 14 to a third party logistics partner "3PL" and 
also to a specific customer 48. (The reference symbols "OEM" and "3PL" actually appear in 
Figure 4, so corresponding reference numbers are omitted from this brief for clarity.) 

sending a request (94 in Figure 4) for real-time data (98 in Figure 4) from a 
network system (14 in Figures 1, 4, 6) to a partner coordinator component (180 in 
Figure 6 - see below) integrated with an existing partner system (18 in Figures 1 
and 6, "3PL" in Figure 4), the real-time data (98 in Figure 4) relating to a 
transaction (defined by communications 82, 90, 92, 94, 96, 98, 100, and 108 or 110 
in Figure 4 - see explanation below) in which the partner (18 in Figure 1 and 6, 
"3PL" in Figure 4) is involved, the network system (14 in Figures 1, 4, 6) 
maintaining a context (136 in Figure 5) for the transaction (defined by 
communications 82 to 110 shown in Figure 4 - see explanation presented below); 

Figure 6 illustrates how a "partner coordinator component 1 80" reformats and transfers 
transaction-related messages between customer and partner enterprise resource planning (ERP) 
applications and systems 182 and 198 and the network domain 14. The "partner coordinator 
component 180" is described in the specification, page 23, lines 9-19, as follows: 

. . . [0]ne or more partner coordinator components 1 80 [Figure 6] may be 
provided at customer domain 20, partner domain 18. ... [T]he partner coordinator 
component 180 provides the network domain 14 with real-time information about 
transactions that are occurring within the supply chain. This real-time information can be 
used to generate, assemble, modify, update, etc., respective contexts for the transactions. 
The partner coordinator may independently "push" out the real-time data to the network 
domain 14 or may provide access to the data for the network domain by cooperating with 
one or more existing (or legacy[)] systems ... at the customer domain 20 or partner 
domain 18. 

The "transaction" is defined by the series of communications, beginning with 82 
(customer service request) and continuing on with the communications 90 (enter service order) 
92 (real-time inventory check), 94 (real-time ship request), 96 (real-time inventory updates), 98 
(service order proof of delivery), and 100 (close service order) and also 108 (ship part) or 1 10 
(dispatch field technician). These communications, taken together, define an illustrative 
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transaction carried out for the customer 48 by the OEM, the network domain 14, and the partner 
3PL. 

The specification, page 17, lines 13-20 begins describing this illustrative "transaction" as 
follows: 

Figure 4 illustrates a number of different actions which may occur in a supply 
chain and some of the features of a network domain 14 .... A customer 48 may make a 
service request 82 to an OEM . . . which can be an enterprise ... [16]. The OEM . . . may 
enter a service order 90 to a network domain 14. One or more real-time inventory checks 
92 may occur between the network domain 14 and the OEM .... The network domain 14 
may make a real-time ship request 94 to a third party logistics (3PL) provider . . ., which 
can be a partner to the OEM .... The 3PL . . . may provide real-time inventory updates 
96. ... [This quote from the specification continues below.] 

The "context for the transaction" is maintained in a data access layer component 136, 
shown in Figure 5, as the specification indicates on page 22, lines 7-10: 

The data access layer component 136 provides access for other components of the 
network domain 14 to databases, such as a lightweight directory access protocol (LDAP) 
database 162 or a relational database (labeled "Oracle" in Fig. 5) 164. The databases 
may store real-time data relating to one or more transactions and may maintain a 
respective context for each transaction. [Emphases added.] 

receiving at the network system (14 in Figures 1, 4, and 6) the real-time 
data (98 in Figure 4) from the existing partner system (18 in Figure 1 and 6, 
"3PL" in Figure 4) in response to the request (94 in Figure 4); and 

The specification, page 17, lines 20-22 continues describing the illustrative "transaction" 
as follows: 

. . . The 3PL may ship a part 108 or dispatch a field technician 1 10 to the customer 48. 
When the service is complete, the 3PL may provide service order proof of delivery status 
98 to the network domain 14, [This quote from the specification continues below.] 

generating a real-time report (100 in Figure 4) using the real-time data 

(98 in Figure 4) for updating the enterprise (16 in Figure 1, "OEM" in Figure 4) 
on the transaction (defined by communications 82 to 1 10 in Figure 4 - see 
explanation above) in which the partner (18 in Figure 1 and 6, "3PL" in Figure 
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4) is involved, thereby providing real-time visibility (370 in Figure 15) into a 
status of the partner (18 in Figure 1 and 6, "3PL" in Figure 4) with respect to 
the transaction (defined by communications 82 to 1 10 in Figure 4 - see 
explanation above). 

The specification, page 17, lines 22-23 concludes describing the illustrative "transaction" 
as follows: 

. . . and the network domain 14 may close the service order 1 00 with the OEM .... 

The specification, page 43, lines 9-14 and page 44, lines 22-27, describes the "real-time 
visibility" of the "transaction" as follows, with reference to Figure 15: 

The graphical user interface 370 may provide an enterprise and its partners with 
dynamic, consistent context-based information to be shared, updated, and acted upon 
according to stringent policy-based application and business rules set up by key 
performance indicators. This allows for a uniform view of the information whether the 
information originated in an enterprise application or a partner application across the 
entire supply chain network. . . . 

The graphical user interface 370 provides a personalized control center for 
visibility and control into a supply chain . . . [and] is fully customizable with the drill- 
down capabilities to view more specific information. With the graphical user interface 
370, an enterprise understands the extended supply chain of itself and its partners and 
end-customers, thereby providing the ability to respond rapidly and efficiently to enhance 
customer satisfaction while reducing operating costs. 



10. The method of claim 7, further comprising converting (a step 
performed by an adaptation component 260, Figure 1 1 , that lies within the partner 
coordinating component 180, Figure 1 1) the real-time data into a format usable 
by the network system (14). 

Figures 1 and 6 illustrate that a supply chain management network (10 in Figures 1 and 6) 
is formed by using a centralized Network Domain (14 in Figures 1 and 6) to interconnect an 
Enterprise Domain (16 in figure 1) with proprietary enterprise resource planning (ERP) 
applications (182 and 196 in Figure 6) that are found within Partner Domains (18 in Figures 1 
and 6) and Customer Domains (20 in Figures 1 and 6). 
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The proprietary enterprise resource planning (ERP) applications (182 and 196 in Figure 
6) and other similar applications found within each partner (18 in Figures 1 and 6) and customer 
(20 in Figures 1 and 6) utilize their own proprietary transaction data formats, and these formats 
are not understandable to the applications within the Network Domain (14 in Figures 1 and 6). 
For example, the Specification says on page 14, lines 8-19: 

The network 10 allows for a non-intrusive business-to-business (B2B) integration. 
The network 10 offers partners multiple connection options to minimize IT investment, 
reduce overhead, and increase adoption rates among partners. The noninvasive system 
components do not replace the infrastructure of an enterprise or a network, but instead 
integrate seamlessly with and enhance the existing infrastructure of an enterprise or a 
partner. The network 10 can support direct, real-time connections to a number of 
enterprise resource planning (ERP), material requirements planning (MRP), supply chain 
management (SCM), customer relationship management (CRM), warehouse management 
systems (WMS), and enterprise application integration (EAI) applications or subsystems 
for direct back-end system integration. Furthermore, the network can support connections 
to databases, spreadsheets, and other software systems used to manage supply chain 
operations. 

A Partner Coordinator (180 in Figure 6 and 1 1) connects the ERAs, etc. (182 and 198 in 
Figure 6) within each Partner and Customer Domain (18 and 20 in Figures 1 and 6) to the 
Network Domain (14 in Figures 1 and 6). To make it possible for all of these diverse 
applications and systems to "understand" each other, the Partner Coordinator (1 80 in Figures 6 
and 11) includes an Adaptation component (260 in Figure 1 1), which performs the new step 
introduced by Claim 10. This new step is described in the specification (page 32, line 32 to page 
33, line 3): 

Adaptation component 260 [Figure 1 1] may convert or adapt the data and 
information between a format that is usable and understood by the existing partner [and 
customer] applications and a format that is usable and understood by the components and 
applications in the network domain 14 [Figures 1 and 6]. 

This new step introduced by claim 10 is thus a step that reformats the real-time data so 
that all of the diverse customer and partner applications (ERP, MRP, SCM, CRM, WMS, EAI, 
etc. listed above) are integrated seamlessly into a global supply chain system. 
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18. A system for reporting in a supply chain (10 in Figures 1 and 6) 
involving an enterprise (16 in Figure 1, "OEM" in Figure 4) and at least one 
partner (18 in Figures 1 and 6, "3PL" in Figure 4), the system comprising: 

Figure 1 illustrates a supply chain system 10 in which an enterprise domain 16 is linked 
by a network domain 14 to multiple partner domains 18 and customer domains 20. Figure 4 
presents a specific example of a transaction where an original equipment manufacturing 
enterprise "OEM" is linked by a network domain 14 to a third party logistics partner "3PL" and 
also to a specific customer 48. (The reference symbols "OEM" and "3PL" actually appear in 
Figure 4, so corresponding reference numbers are omitted from this brief for clarity.) 

a database (136 in Figure 5) operable to maintain a context for a 
transaction in which the partner ( 1 8 in Figures 1 and 6, "3PL" in Figure 4) is 
involved; 

In the specification, the "database" is referred to as the "data access layer component 
136" of the "network domain 14," and appears in Figure 5. The specification describes the 
component 136 as follows (page 22, lines 8 to 12): 

The data access layer component 136 provides access for other components of the 
network domain 14 to databases, such as a lightweight directory access protocol (LDAP) 
database 162 or a relational database (labeled "Oracle" in Fig. 5) 164. The databases 
may store real-time data relating to one or more transactions and may maintain a 
respective context for each transaction. The use of the LDAP 162 provides for the 
distribution of key information throughout the [supply chain] network 10 for access by 
network system components. . . . [Emphasis added.] 

a processor (132) coupled to the database , the processor operable to: 

The "processor" also appears in Figure 5, where it is referred to as the "process execution 
component 132." This component includes software that carries out business workflow 140, 
exception workflow 142, and routing workflow 144. These workflows include processes which 
execute tasks. The workflows 140, 142, and 144 are initiated by transactions, requests, and 
demands. The workflows 140, 142, and 144 can access real-time data relevant to a transaction 
and can obtain such data from a partner system 18 or from the "database," the data access layer 
component 136. The workflows 140, 142, and 144 are assisted by a "business data managers 
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component 134" which maintains, among other things, the policies and practices specific to an 
enterprise's 16 way of doing business with a partner 18. (See specification, page 21, lines 6-30.) 

send a request (94 in Figure 4) to a partner coordinator component 
(180 in Figure 6 - see below) integrated with an existing partner system (18 in 
Figures 1 and 6, 3PL in Figure 4) for access to real-time data (98 in Figure 4) 
relating to a transaction (defined by communications 82, 90, 92, 94, 96, 98, 100, 
and 108 or 1 10 shown in Figure 4 - see explanation presented below) in which 
the partner (18 in Figures 1 and 6, 3PL in Figure 4) is involved; 

Figure 6 illustrates how a "partner coordinator component 1 80" reformats and transfers 
transaction-related messages between customer and partner enterprise resource planning (ERP) 
applications and systems 182 and 198 and the network domain 14. The "partner coordinator 
component 180" is described in the specification, page 23, lines 9-19, as follows: 

. . . [0]nc or more partner coordinator components 1 80 [Figure 6] may be 
provided at customer domain 20, partner domain 18. ... [T]he partner coordinator 
component 180 provides the network domain 14 with real-time information about 
transactions that are occurring within the supply chain. This real-time information can be 
used to generate, assemble, modify, update, etc., respective contexts for the transactions. 
The partner coordinator may independently "push" out the real-time data to the network 
domain 14 or may provide access to the data for the network domain by cooperating with 
one or more existing (or legacy[ ) ] systems ... at the customer domain 20 or partner 
domain 18. 

The "transaction" is defined by the series of communications, beginning with 82 
(customer service request) and continuing on with the communications 90 (enter service order) 
92 (real-time inventory check), 94 (real-time ship request), 96 (real-time inventory updates), 98 
(service order proof of delivery), and 100 (close service order) and also 108 (ship part) or 1 10 
(dispatch field technician). These communications, taken together, define an illustrative 
transaction carried out for the customer 48 by the OEM, the network domain 14, and the partner 
3PL. 

The specification, page 17, lines 13-20 begins describing this illustrative "transaction" as 
follows: 
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Figure 4 illustrates a number of different actions which may occur in a supply 
chain and some of the features of a network domain 14 .... A customer 48 may make a 
service request 82 to an OEM . . . which can be an enterprise ... [16]. The OEM . . . may 
enter a service order 90 to a network domain 14. One or more real-time inventory checks 
92 may occur between the network domain 14 and the OEM .... The network domain 14 
may make a real-time ship request 94 to a third party logistics (3PL) provider . . ., which 
can be a partner to the OEM .... The 3PL . . . may provide real-time inventory updates 
96. ... [This quote from the specification continues below.] 

receive the real-time data (98 in Figure 4) from the existing partner 
system (18 in Figures 1 and 6, "3PL" in Figure 4) in response to the request (94 
in Figure 4); and 

The specification, page 17, lines 20-22 continues describing the illustrative "transaction" 
as follows: 

. . . The 3PL may ship a part 108 or dispatch a field technician 1 10 to the customer 48. 
When the service is complete, the 3PL may provide service order proof of delivery status 
98 to the network domain 14. . . [This quote from the specification continues below.] 

generate a real-time report (100 in Figure 4) using the real-time data 

(98 in Figure 4) for updating the enterprise (16 in Figure 1, "OEM" in Figure 4) 
on the transaction (defined by the communications 82 to 1 10 in Figure 4 - see 
the explanation above) in which the partner (18 in Figures 1 and 6, "3PL" in 
Figure 4) is involved, thereby providing real-time visibility into a status of the 
partner (18 in Figures 1 and 6, "3PL" in Figure 4) with respect to the 
transaction (defined by the communications 82 to 1 10 in Figure 4 - see the 
explanation above). 

The specification, page 17, lines 22-23 concludes describing the illustrative "transaction" 
as follows: 

. . . and the network domain 14 may close the service order 1 00 with the OEM .... 

The specification, page 43, lines 9-14 and page 44, lines 22-27, describes the "real-time 
visibility" of the "transaction" as follows, with reference to Figure 15: 
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The graphical user interface 370 may provide an enterprise and its partners with 
dynamic, consistent context-based information to be shared, updated, and acted upon 
according to stringent policy-based application and business rules set up by key 
performance indicators. This allows for a uniform view of the information whether the 
information originated in an enterprise application or a partner application across the 
entire supply chain network. . . . 

The graphical user interface 370 provides a personalized control center for 
visibility and control into a supply chain . . . [and] is fully customizable with the drill- 
down capabilities to view more specific information. With the graphical user interface 
370, an enterprise understands the extended supply chain of itself and its partners and 
end-customers, thereby providing the ability to respond rapidly and efficiently to enhance 
customer satisfaction while reducing operating costs. 



Claims 7-12 and 18-22 stand rejected under 35 U.S.C. §102(b) as being anticipated by 
Mowery, et al (U.S. Patent no. 5,983,198). 

Claims 10 and 1 1 stand rejected under 35 U.S.C. § 103(a) as being obvious in view of 
Mowery, et al. 

Applicants traverse these rejections. 



VI. Grounds of Rejection to be Reviewed on Appeal 
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VII. Argument 

The claims have been grouped into two groups to facilitate this appeal. 

In Section A below, all of the claims are grouped together. Applicants suggest 
independent claim 7, a method claim, to be a representative claim. Independent claim 18 is 
similar to claim 7 in scope and in inventive spirit, but is formulated as an apparatus claim. The 
remaining claims 8-12 and 19-22 are all dependent upon these two claims. 

In Section B, which follows Section A, the two dependent claims 10 and 1 1 are grouped 
together for argument purposes, and applicants suggest claim 10 to be a representative claim. 
Dependent claim 10 is dependent upon independent claim 7, and claim 1 1 in its turn is dependent 
upon claim 10. 

The patentability of claims 8-9, 11, and 18-22 are not argued separately in this appeal. 

A. Rejection of Claims 7-12 and 18-22 as Anticipated Under 35 U.S.C. 102(e) 

/. The transaction oriented methods and systems of the invention as claimed, involving 
commun icatio ns concerning commercial transactions between an enterprise and 
its trading partners, are patentable over the non-transaction oriented inventoiy 
management system of Mowery, et al. 

The Examiner asserts that: 

Mowery shows sending a request from a network for real time data comprising, 
for instance, [the] inventoiy level of a partner; receiving the real-time data from the 
partner; and generating a real-time report using the data providing visibility into the 
status of the partner. (Final Rejection mailed 06/02/2006, page 2, lines 1 1-14) 

Respectfully, Mowery, et al. do not disclose anything about transaction oriented methods 
and systems that involve real-time data relating to supply chain transactions in which an 
enterprise and at least one of its business partners are involved, as recited in the claims on 
appeal. 

The reference relied upon by the Examiner shows a system directed toward maintaining 
the level of a liquid commodity on a customer site by directly monitoring the customer's tanks, 
telemetering how full and how hot the tanks are to a central station, reviewing past usage 
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patterns of the customer, and then scheduling fuel deliveries accordingly. (Col. 3, lines 36-44.) 
More specifically, level sensors 108 and temperature sensors 1 10 are installed on tanks 104 at 
customers' plants 102. (Col. 3, lines 51-58.) Temperature and level signals generated by these 
sensors are broadcast by remote telemetry units 1 12 to a central station 1 14. (Col. 3, lines 58- 
65.) The telemetry data is processed at the central station 1 14 by information systems that store, 
analyze and report inventory and usage patterns. (Col. 4, lines 13-16.) Material consumption at 
each plant 102 is predicted based on each particular plant's historical consumption pattern and 
available information on future changes. Then and product delivery is optimally scheduled by 
the central station 114 such that the delivery of raw materials to the tanks 104 is customized to fit 
the particular needs of the particular plant 102. (Col. 4, lines 1 8-24.) The reference relied upon 
is thus directed toward maintaining an inventory of a liquid commodity at plant sites and does 
not appear to contain any disclosure related to the management of complex transactions between 
an enterprise and its trading partners. 

In contrast to this, the present invention is directed toward supply chain transaction 
oriented methods and systems involving an enterprise and at least one of its trading partners . 
Claim 7 recites "sending a request for real-time data from a network system to a partner 
coordinator component integrated with an existing partner system , the real-time data relating to a 
transaction in which the partner is involved" and "generating a real-time report using the real- 
time data for updating the enterprise on the transaction in which the partner is involved". 
(Emphasis added.) Claim 18 recites "a database operable to maintain a context for a transaction 
in which the partner is involved" and a processor operable to "send a request to a partner 
coordinator component integrated with an existing partner system for access to real-time data 
relating to a transaction in which the partner is involved" and "generate a real-time report using 
the real-time data for updating the enterprise on the transaction in which the partner is involved". 
(Emphasis added.) 

The claims require the transactions to be carried out between an enterprise and its partner . 
Additionally, the existing computer systems of the partner must be modified by the addition to 
them of a partner coordinator component 180. This partner coordinator component 180 then 
enables the existing partner systems to respond to requests for real-time data that are generated 
by the enterprise and by its centralized network domain processes. None of this is taught in the 
Mowery, et al. patent cited by the Examiner. 
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The specification gives as examples of transaction data "numbers for purchase orders, 
shipping receipts, [and] invoices for various transactions in which the respective partner is 
involved." (Page 18, lines 17-19.) The specification describes a "workflow" that "may be 
initiated by a transaction , a request, or a demand. ..." [T]he workflows "may access real-time 
data relevant to a transaction from an existing partner system . . . and process a request for a 
transaction in the context [of] ... the transaction ." (Page 21, lines 9-13, emphasis added.) At 
page 22, lines 7-11, the specification describes a database that stores real-time data relating to 
transactions. Figure 4 and page 17, lines 13-24 of the specification present an illustrative 
scenario of how a particular transaction might flow through the network 10. The present 
invention is thus directed toward methods and systems for accomplishing and reporting the 
transactions that occur in a supply chain involving an enterprise and at least one partner. 

The "partner coordinator component 180" is described in the specification, page 23, lines 
9-19, as follows: 

. . . [0]ne or more partner coordinator components 1 80 [Figure 6] may be 
provided at customer domain 20, partner domain 18. ... [T]he partner coordinator 
component 180 provides the network domain 14 with real-time information about 
transactions that are occurring within the supply chain. This real-time information can be 
used to generate, assemble, modify, update, etc., respective contexts for the transactions. 
The partner coordinator may independently "push" out the real-time data to the network 
domain 14 or may provide access to the data for the network domain by cooperating with 
one or more existing (or legacy[ ) ] systems ... at the customer domain 20 or partner 
domain 18. 

The claims require the partner coordinator component 1 80 to be integrated into, and 
thereafter to provide connectivity to a wide range of existing partner systems at the site of a 
supply chain partner. The following passage from the specification indicates the wide range of 
existing partner systems that the partner coordinator component 180 can be integrated into: 

The network 10 allows for a non-intrusive business-to-business (B2B) 
integration. The network 10 offers partners multiple connection options to minimize IT 
investment, reduce overhead, and increase adoption rates among partners. The 
noninvasive system components do not replace the infrastructure of an enterprise or a 
network, but instead integrate seamlessly with and enhance the existing infrastructure of 
an enterprise or a partner. The network 10 can support direct, real-time connections to a 
number of enterprise resource planning (ERP), material requirements planning (MRP), 
supply chain management (SCM), customer relationship management (CRM), warehouse 
management systems (WMS), and enterprise application integration (EAI) applications or 
subsystems for direct back-end system integration. Furthermore, the network can support 
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connections to databases, spreadsheets, and other software systems used to manage 
supply chain operations. 

There is no disclosure at all in the Mowery, et al. patent about partner coordinator systems, much 
less about them being integrated into diverse existing proprietary partner systems. 

2. The Examiner has given the term 'transaction ' an unreasonably broad interpretation. 

The Examiner further says, in the Final Office Action mailed June 2, 2006 (page 4, line 
13 to page 5, line 4): 

[T]he meaning of transaction is not limited to a financial or commercial 
transaction between two parties. It can refer to a transaction within a group... and it can 
refer to non-financial transactions. . . . 

[E]ven if it is assumed that the transaction must be a financial one between the 
customer (the partner) and another party (the vendor delivering the resource to the 
customer - the enterprise), the requests for data are for data relating to a transaction. 
They are for inventory levels at the customer, and those inventory levels are related to the 
transaction because upon reaching a certain inventory level the enterprise delivers and 
sells more product to the customer. The reports are likewise related to the transaction. 

Applicants respectfully submit that the Examiner's construction is unreasonably broad. 

Claims are not to be read in a vacuum, and limitations therein are to be interpreted 
in light of the specification in giving them their 'broadest reasonable interpretation'", In 
reMarosi, 710 F.2d 799, 802, 218 USPQ 289, 292 (Fed. Cir. 1983). 

The Examiner's construction of the term transaction appears to be unreasonably broad in view of 
the specification and confuses a transaction with its component tasks, events or other actions. 

The specification makes clear that the transactions at issue relate to a business context. 
(Page 16, lines 2-20.) Examples of the types of transactions contemplated include a purchase 
order, a service request, an installation request, a warranty matter, or a replacement request. 
(Page 16, lines 6-7.) The specification also distinguishes between a transaction and the tasks, 
events or other action in the supply chain related to the transaction. (See page 16, lines 12-16; 
page 17, lines 29-32; and page 18, lines 17-24.) The Examiner's equating a transaction with the 
tasks, events or other individual actions within a supply chain that are related to or that form 
elements of that transaction is unreasonably broad in light of the specification. 
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3. The reference relied upon does not disclose each and every limitation of the claimed 
invention. 

The Examiner fails to point out where Mowery et al. disclose certain elements of the 
claimed method and system for reporting. The claimed system and method include "a partner 
coordinator component integrated with an existing partner system " and also require " providing 
real-time visibility into a status of the partner with respect to the transaction ." The Mowery et al. 
patent does not mention any partner coordinator component at all; much less does it disclose 
integrating such a component into some existing system of a "partner" in the supply chain. The 
Mowery et al. patent also never mentions "partners" at all - the patent only speaks of 
"customers." In the specification, a "customer" is an end-user, such as a consumer. (Page 16, 
line 7-10.) In Figure 1, there are both customer domains 20 and partner domains 18. The 
Mowery et al. patent discloses the provision of a central station 1 14, operated by a material 
supplier, for controlling the delivery of a material directly to its customers, not to any partner, 
and not with the assistance or cooperation of any partner. The Examiner points to no actual third 
party partner involvement in the Mowery, et al. patent. There is also no disclosure in the 
Mowery et al. patent that the "status" of "the partner with respect to a transaction" is to be made 
"visible" in "real-time," as all of the claims require. 

Because the Examiner has failed to point out where each and every limitation of the 
claims is disclosed in the prior art, applicants respectfully submit that the claim rejections are 
improper. 

B. Rejection of Claims 10 and 11 under 35 U.S.C. 102(b) and 35 U.S.C. 103(a) 

Dependent claim 10 adds to independent claim 7 one additional element: the step of 
"converting the real-time data into a format usable by the network system." 

This conversion is performed by an adaptation component (260 in Figure 11) part of a 
partner coordinator (180 in Figures 6 and 11), which, in response to requests for real-time data, 
accepts or fetches proprietary transaction data from proprietary systems found within the domain 
of each partner or customer (18 and 20 in Figure 6), transforms the proprietary transaction data 
into a standardized format, and then sends the transaction data across a network (12 in Figure 1) 
to a central network domain (14 in Figures 1 and 6). As to this, the specification (page 32, line 
32 to page 33, line 3) says: 
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Adaptation component 260 may convert or adapt the data and information 
between a format that is usable and understood by the existing partner [and customer] 
applications and a format that is usable and understood by the components and 
applications in the network domain 14. 

The Examiner has rejected this claim twice: first under 35 U.S.C. 102(b) "as anticipated 
by . . . Mowery" and secondly under 35 U.S.C. 103(a) "as obvious over Mowery." This dual 
rejection is mutually inconsistent with itself, and accordingly it is not legally sound. It must be 
reversed. 

With respect to the Examiner's rejection of claim 10 under 102(b), the Examiner admits, 
in his alternative rejection of claim 10 under 103(a), that an entirely new element (or step) of the 
invention is introduced by claim 10 - an element that is not disclosed in Mowery, et al. The 
Examiner says: " 

Mowery shows all elements [of claim 10] except converting the data into data 
usable by the network. (Final Rejection mailed 04/1 8/2007, page 3, lines 20-21) 

The Examiner thus admits that the new element (or step) added by claim 10, the step of 
"converting the real-time data into a format usable by the network system," is entirely missing 
from Mowery, et al. Mowery, et al. discloses only a closed, proprietary system whose 
proprietary transaction data never needs to be reformatted into a standardized format so that it 
can be stored centrally and then shared over a network with an enterprise other systems of 
partners and customers that have their own proprietary data formats. 

But if Mowery, et al. does not disclose the new element (or step) defined by claim 10, 
then Mowery, et al. does not "anticipate" claim 10 under 102(b). As Robert Harmon says in his 
treatise on Federal Circuit patent law: 

Under modern decisions, anticipation requires that each and every element of the 
claimed invention be disclosed in a single prior art reference ..." Robert L. Harmon, 
Patents and the Federal Circuit, page 90 (6 th Ed. BNA 2003). 

Accordingly, the Examiner's rejection of claim 10 as unpatentable under 35 U.S.C. 102(e) is 
unsound and must be reversed, since the Mowery, et al. patent fails to disclose an element of the 
invention defined by the combination of claims 7 and 10. (And, of course, Mowery, et al. also 
fails to disclose additional elements of claim 7, as was explained above.) 
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With respect to the Examiner's alternative rejection of claims 10 under 103(a), after 
admitting that Mowery, et al. does not disclose the step of "converting the data into data usable 
by the network," the Examiner fails to cite a second reference which does disclose this element 
of the combination. The Examiner thus relies only upon Mowery, et al. in support of his 
obviousness rejection of these two claims. The Examiner says: 

Mowery shows all elements except converting the data into data usable by the 
network. However, to convert data from an outside system to data usable by another 
system is notoriously old and well known in the art. It would have been obvious to one 
of ordinary skill in the art to do so in order to allow the system to successfully use the 
information. ((Final Rejection mailed 04/18/2007, page 3, line 20 to page 4, line 2) 

The Examiner should have cited a second reference - say a patent or an article - that disclosed 
the added step introduced by claim 10 of converting the proprietary data of a partner or customer 
into "a format usable by the network system." Then applicants could have studied both 
references and then determined, for example, whether the second reference was rationally 
combinable with Mowery, et al, or whether the second reference was entirely unrelated and 
irrelevant to Mowery, et al. (Or perhaps Applicants would have agreed with the Examiner.) 

By not citing any second reference at all, and by relying instead upon the fact that the 
step introduced by claim 10 which does not appear in Mowery, et al. is "notoriously old and well 
known in the art," the Examiner has failed to establish a prima facie case of obviousness. To 
quote the Manual for Patent Examining Procedure: 

To establish a prima facie case of obviousness, three basic criteria must be met: 
. . . Finally, the prior art reference (or references when combined) must teach or suggest 
all the claim limitations . The teaching or suggestion to make the claimed combination . . . 
must . . . be found in the prior art .... (Emphasis added - MPEP, §706.020'), page 700-48, 
Rev. 5, Aug. 2006) 

Since the Examiner has failed to establish a prima facie case of obviousness, the rejection 
is improper as a matter of law; and applicants do not need to respond to this incomplete and 
improper rejection. 

Without conceding this point, an evaluation of the Mowery, et al. patent further reveals 
that it does not render the present invention as claimed in claims 7 and 10 obvious. The Mowery, 
et al. patent discloses a proprietary inventory monitoring and liquid material delivery system, 
shown in Figure 1 . It is not a supply side computer network, interchanging purchase and sale 
orders, inventory information, and the like among different trading partners and customers 
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having incompatible computer systems, unlike the invention defined by claims 7 and 10. In 
Figure 1 of the Mowery, et al. patent, several tanks 104 located at a plant 192 are each monitored 
by ultrasonic liquid level sensors 108 "manufactured by Electronic Sensors, Inc." (Mowery, et 
al, Col. 3, lines 51-54) and by thermocouple temperature sensors 1 10. (Col. 3, lines 54-58) 
Signals from these level sensors 108 and thermocouple temperature sensors 110 "are provided to 
a remote telemetry unit (RTU) 112 which is programmed to communicate information to a 
central station 114 via standard voice telephone lines . . . ." (Col. 3, lines 54-63) The central 
station then sends out "a fleet of vehicles 118" to deliver "the various products to the tanks." 
(Col. 4, lines 26-28) Invoices and usage information are then sent to customers 126. (Col. 5, 
lines 2-5) 

Since the level sensors 108 all come from one supplier and are thus presumably identical 
as to the signals they generate, and since the thermocouples 1 10 are, by their very nature, also 
identical as to the signals they generate, there is absolutely no reason in Mowery, et al. for 
"converting the real-time data into a format usable by" the central station 114 before the data is 
sent to that central station 1 14, as claim 10 requires. No mechanism for performing such a 
conversion is disclosed. Likewise, the invoices sent to customers are presumably human 
intelligible and also require no "converting" into some standardized format. Hence, the Mowery, 
et al. patent does not disclose any "converting . . . data into a format" step, and by its very nature, 
the Mowery, et al. system does not require such a step. Thus, the Mowery, et al. patent does not 
render the invention, as claimed by claims 7 and 10, obvious to one skilled in the art. 

The present invention teaches interfacing the supply chain system to many different 
customer and partner-supplier software systems, all of which have their own proprietary ways of 
formatting their data. For example, the specification, page 14, lines 8-19 says: 

The network 10 allows for a non-intrusive business-to-business (B2B) 
integration. The network 10 offers partners multiple connection options to 
minimize IT investment, reduce overhead, and increase adoption rates among 
partners. The noninvasive system components do not replace the infrastructure of 
an enterprise or a network, but instead integrate seamlessly with and enhance the 
existing infrastructure of an enterprise or a partner. The network 10 can support 
direct, real-time connections to a number of enterprise resource planning (ERP), 
material requirements planning (MRP), supply chain management (SCM), 
customer relationship management (CRM), warehouse management systems 
(WMS), and enterprise application integration (EAI) applications or subsystems 
for direct back-end system integration. Furthermore, the network can support 
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connections to databases, spreadsheets, and other software systems used to 
manage supply chain operations. 

To make it possible for all of these diverse applications and systems to "understand" each 
other, a Partner Coordinator (180 in Figures 6 and 1 1) is integrated into each of these proprietary 
systems. And to reformat the data produced by these proprietary systems into a format 
intelligible to the remainder of the supply chain system 10, each Partner Coordinator includes an 
Adaptation component (260 in Figure 1 1), which performs the new reformatting step that is 
introduced by Claim 10. This new reformatting step is described in the specification (page 32, 
line 32 to page 33, line 3): 

Adaptation component 260 [Figure 11] may convert or adapt the data and 
information between a format that is usable and understood by the existing partner [and 
customer] applications and a format that is usable and understood by the components and 
applications in the network domain 14 [Figures 1 and 6]. 

Claim 10 is directed to the inclusion of this adaptation component 260 (Figure 1 1) with 
the other elements of claim 7 so that the modified proprietary partner systems are capable of 
"converting the real-time data into a format usable by the network system." (Claim 10) No such 
component can be found in the Mowery, et al. patent; and accordingly, claims 10 and 7 together 
define invention over the art of record. 

C. Conclusion 

Nothing in Mowery, et al. appears to disclose the transaction-oriented methods and 
systems of the invention as claimed for enabling an enterprise and its partners to perform 
transactions. Nothing in Mowery, et al. appears to disclose integrating a partner coordinator 
component into existing proprietary partner computer systems to couple them into an enterprise 
supply chain network having other partners. And (with respect to dependent claim 10), nothing 
in Mowery, et al. appears to disclose including in such a partner coordinator an adaptation 
component that can reformat proprietary customer data to make the data understandable to other 
components of such a supply chain. 

Applicants respectfully submit that the pending claims are patentable over the reference 
relied upon by the Examiner. For the reasons given above, the present invention is considered to 
be in proper condition for allowance and action to that end is respectfully requested. 
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VIII. CLAIMS APPENDIX 

1-6. (Withdrawn) 

7. (Original) An automated method for reporting in a supply chain involving 
an enterprise and at least one partner, the method comprising: 

sending a request for real-time data from a network system to a partner 
coordinator component integrated with an existing partner system, the real-time data relating to a 
transaction in which the partner is involved, the network system maintaining a context for the 
transaction; 

receiving at the network system real-time data from the existing partner system in 
response to the request; and 

generating a real-time report using the real-time data for updating the enterprise 
on the transaction in which the partner is involved, thereby providing real-time visibility into a 
status of the partner with respect to the transaction. 

8. (Original) The method of claim 7, wherein the real-time data comprises 
transaction data involving a status of the transaction. 

9. (Original) The method of claim 7, wherein the real-time data comprises 
reference data related to the partner. 
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10. (Original) The method of claim 7, further comprising converting the real- 
time data into a format usable by the network system. 

1 1 . (Original) The method of claim 10, wherein converting comprises 
formatting the real-time data into extensible markup language (XML) format. 

12. (Original) The method of claim 7, further comprising validating the real- 
time data against the context maintained for the transaction. 

13-17. (Withdrawn) 

18. (Original) A system for reporting in a supply chain involving an enterprise 

and at least one partner, the system comprising: 

a database operable to maintain a context for a transaction in which the 

partner is involved; and 

a processor coupled to the database, the processor operable to: 
send a request to a partner coordinator component integrated with an 

existing partner system for access to real-time data relating to a transaction in which the partner 

is involved; 

receive the real-time data from the existing partner system in response to 

the request; and 
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generate a real-time report using the real-time data for updating the 
enterprise on the transaction in which the partner is involved, thereby providing real-time 
visibility into a status of the partner with respect to the transaction. 

19. (Original) The system of claim 1 8, wherein the processor is operable to 
generate a graphical user interface for presenting the report. 

20. (Original) The system of claim 19, wherein the report compromises an 
alert report to notify the partner of the status of the transaction. 

2 1 . (Original) The system of claim 1 9, wherein the report comprises a task 
report to notify the partner of a task relating to the transaction to be performed. 

22. (Original) The system of claim 19, wherein the report comprises an 
inventory report to update the enterprise or the partner of an inventory level relating to the 
transaction. 

23-26. (Withdrawn) 
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IX. EVIDENCE APPENDIX 

None. 
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X. RELATED PROCEEDINGS APPENDIX 

None. 
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